A Newcomer's Guide to Bug Design

An Open Letter to New Bug Authors

Why this guide?

You've bested the bugs that come with AI Wars. You even beat lrscanner and Survivor. Your bug can take on all of the swarm bugs, alone. You're tough. You know it. You've gone as far as you can go. You download a tournament class bug from the Internet. You get slaughtered. You panic...

This happened to me and I think it happens to a lot of people. Don't get discouraged! The AI Wars language has a lot of room for optimizations in it--far more than you'd imagine at first, especially if you have any formal Computer Science training.

This guide gives newcomers some places to start looking when they want to radically speed up their bugs. Some of the tips in here have, until now, been considered by the few that knew them to be absolutely top secret.

The Tournament Difference

I will refer in this guide to three kinds of bugs: Tournament class bugs, Newcomer bugs, and Sample bugs. The sample bugs are the ones that ship with AI Wars. Newcomer bugs are bugs written by new users when they first download AI Wars. Tournament bugs are bugs that use the tricks and techniques that have evolved on various tournament sites over time.

Tournament bugs were very intimidating for me at first, since they so easily dispatched the bug that I had worked on so hard. They generally use common techniques and strategies that make them much more successful than the sample bugs. As new techniques emerge, they are adopted by others for their own bugs, thus causing tournament bugs to evolve. Here are some common differences between tournament bugs and newcomer bugs, as well as some great ways to speed up your bugs.

Primary Weapons vs Missiles

I've only seen one or two tournament bugs successfully use "Fire Weapon" to attack an enemy, although I believe this will change in the future. Fire Weapon does almost no damage to a shielded bug unless at extremely close range. Since most bugs run around with their shields up most of the time, most users choose missiles as the weapon of choice.

Discharging Energy

Before downloading and watching a few tournament bugs, I never discharged energy. Not only was it not very effective (causing only three points of damage) but it also cause damage to the attacking bug! There were no sample bugs that used it well.

A tournament bug, when it detects an enemy on the perimeter, typically flashes it's "discharge energy" four times in a row (4 * 3pts damage > 10) to immediately kill the opponent. So if you end up next to a tournament bug and it scans you first, you die. Fast. Once you die, it takes your flag to recover any damages and pick up ammo.

Getting Flags

Which brings me to another major difference. Almost all tournament bugs seem to have a fixation for flags, even when they are perfectly healthy. Reading the documentation and competing with the sample bugs got me thinking that I should avoid flags like the plague, unless I was injured. Most newcomer bugs do just that: they ignore or specifically avoid flags when they aren't injured.

Here are the advantages that come with picking up a flag. Every flag (in 3.7c, where the tournaments are run) represents 30 ammo points. That's three missiles! It also represents complete repairs of any damage and 350 units of fuel. 30 ammo points is the really tempting part for most bugs. Nearly all tournament bugs will deliberately hurt themselves with a discharge so that they can pick up a flag safely.

Counting Clicks

The heartbeat of a bug is the click. Everything--and I mean EVERYTHING--is tuned and designed around the click. Knowing how to count clicks is the key to the rest of this guide.

For sharware users, one line is one click, except for blank lines and comments. This includes line labels, returns, gotos, "end if" lines, etc. Tournaments at Battle Dome no longer use this method. This 3.7c introduces a "smart click" mode that makes counting clicks much harder, but makes it much easier to optimize your bugs. Shareware users should keep this counting method in mind when they write their bugs

Type of operation	number of clicks
Moving, turning, and firing weapons	1 full click
All scans	3/10 of a click
"logic" commands	1/10 of a click
blank lines, labels, goto, gosub, name, password, and author commands	zero clicks

Assign

Assign and Math are the only two places where there is no ~ in front of a variable. This trips me more times than I care to imagine.

You can assign just about anything to a variable. This is mentioned in the official guide, but not stressed. Why does this matter? You can have a self-programming bug, in effect. For example,

Example: Planning ahead

if value #x_pos > #enemy_x then assign vT TURN RIGHT
if value #x_pos < #enemy_x then assign vT TURN LEFT
move forward
move forward
move forward
~vT

this code figures out which direction to turn early on, and records the command it will have to perform later. This way when it gets where it's going it can turn faster than if it needed to figure out the direction on the fly.

GPS Scan

I looked long and hard before I ever found a use for GPS scan. It took me too long to calculate the X and Y coordinates needed for evaluation. I know of one or two bugs use it, usually to scan the other side of mines. Here are some other uses:

gps scan x #friend_x y #friend_y

If this scan finds a friend, you're not the only bug left on your team. If this scan didn't find a friend, you're the only one with your IFF code left.

gps scan x #strat_x y #strat_y

This scans the strategy node and tells you if an enemy is racking up points there.

gosub/goto

A warning about gosub and goto: Unless running under 3.7c rules (smart clicks), the goto and the label you are jumping to counts as clicks, so every goto has at least a one-click overhead.

You can use goto to jump to variables as well. For example,

Example: Jumping to user variables

assign vG move
goto ~vG

What does this help with? Not much. But use this with a system variable, you can do amazing things. This code does a long range scan, then immediately jumps to exactly the right routine to process what it finds: (note: only works with versions 2.1c and higher)

Example: Jumping to system variables

long range scan
gosub #scan

1:
return

2:
   lower shields
   launch missile
   raise shields
   return

3:
   scan perimeter
   if scan found mine then discharge energy
   return

4:
return

5:
goto GetFlag

This is a very very fast method for processing scans. Adding some nested "if" statements to the beginning (discussed next) will improve this even more.

Note that if you repeatedly gosub to a label that doesn't exist, your bug will eventually stop working, and all gosub statements will fail.

If...

First, it is a complete waste to use the form

Example: If ... Then ... End If

If scan found enemy then
move backward
launch missile
end if

In 2.1c, this takes 4 clicks, whether the if statement is true or not. The "if" and the "end if" take one click a piece. In 3.7c, the "if" and "end if" still (apparently) count seperately. Re-writing like this:

Example: If ... Then ... Command

If scan found enemy then move bakwards
If scan found enemy then launch missile

takes only 2 clicks, and does exactly the same thing. Anything more than two lines should be a goto.

Additionally, you can string as many If ... then if ... then if ... then statements on a line as you want without adding time to the processing. So the following code

Example: Discharging safely

if value #cur_life <9 then discharge energy
if value #cur_life <9 then discharge energy
if value #cur_life <9 then discharge energy
if value #cur_life <9 then discharge energy

discharges energy just as fast as just having four discarge energy commands, with no danger of suicide.

Using if's after scanning can save several clicks. Since most bugs don't want to do anything if a scan turns up nothing, a barrier, or a friend, using nested if statements can save a lot of time (especially when combined with the previous tip):

Example: Very fast scanning

long range scan
if value #scan <> 0 then if value #scan<> 1 then if value #scan <> 4 then goto #scan

2:
   lower shields
   launch missile
   raise shields
   return

3:
   scan perimeter
   if scan found mine then discharge energy
   return

5:
goto GetFlag

Name

Your bug can change names at any time in its execution. This can be a big debugging tool, since you can turn on cybug names while the bugs are battling. This gives your bugs a method for communicating with the outside world (or just you). In 3.7c, this name change doesn't even use a click.

Do you have more?

Do you have more tips, ideas, or hints for others? Let me know and I'll add it to this list. My goal here is not to give away anybody's secrets, but to increase the quality and quantity of bug writers everywhere! Remember that the more AI Programmers out there who stick with it, the more fun the game will be for everyone.

What gave you the most problems as you started competing on-line? What struck you as odd in the behavior of others? What should new users know?